<html>
<head><meta charset="utf-8"><title>Rust inconsistencies, and roadmap possibilities · general · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/index.html">general</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Rust.20inconsistencies.2C.20and.20roadmap.20possibilities.html">Rust inconsistencies, and roadmap possibilities</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="199659640"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Rust%20inconsistencies%2C%20and%20roadmap%20possibilities/near/199659640" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Rust.20inconsistencies.2C.20and.20roadmap.20possibilities.html#199659640">(Jun 03 2020 at 18:43)</a>:</h4>
<p>This thread is worth reading: <a href="https://www.reddit.com/r/rust/comments/gvqhea/rust_seems_like_the_most_consistent_language_ive/">https://www.reddit.com/r/rust/comments/gvqhea/rust_seems_like_the_most_consistent_language_ive/</a></p>



<a name="199659684"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Rust%20inconsistencies%2C%20and%20roadmap%20possibilities/near/199659684" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Rust.20inconsistencies.2C.20and.20roadmap.20possibilities.html#199659684">(Jun 03 2020 at 18:43)</a>:</h4>
<p>We may be able to learn something from the inconsistencies people point out, which we could potentially improve in a future edition (2021 or otherwise).</p>



<a name="199867681"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Rust%20inconsistencies%2C%20and%20roadmap%20possibilities/near/199867681" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Rust.20inconsistencies.2C.20and.20roadmap.20possibilities.html#199867681">(Jun 05 2020 at 12:19)</a>:</h4>
<p>From the top of my head:</p>
<ul>
<li><code>FromStr</code> using <code>Err</code> instead of <code>Error</code></li>
<li>rarely seemingly arbitrary abbreviations, typing a view letters more normally doesn't hurt anyone</li>
<li><code>&amp;mut</code> having some pseudo <code>Copy</code> behaviour which any struct wrapping a <code>&amp;mut</code> can't have without additional verbosity (<a href="https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2018&amp;gist=71ab71dcf82feeecb877f68428d1f82e">https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2018&amp;gist=71ab71dcf82feeecb877f68428d1f82e</a>)</li>
<li>field access allows splitting a <code>&amp;mut</code> into multipl <code>&amp;mut</code>'s but once accessors (get/set) are used this won't work anymore</li>
<li><code>impl Trait</code> being one syntax used for two completely separate features depending on context. Making it easier to use if you don't try to understand what it does, but harder to properly understand it IMHO. Also making discussion for existential impl trait in other positions (like fields) more complex.</li>
<li><code>impl Trait</code> as generics syntax sugar just working with a small subset of generics, even just having a parameter which is a closure with a generic type parameter requires going back to traditional generics</li>
<li>features and optional dependencies being treated the same from the outside (opt. deps. can be enabled like features) but it's not possible to have a feature and opt. dep. with the same name, nor can a opt. dep. specify other opt. dependencies</li>
<li>rust having a way to specify unstable thinks in lib std, but external libraries can not do so</li>
<li>certain methods only work for "Any" trait objects but not for other trait objects</li>
<li>inconsistent and incomplete derives for std traits</li>
<li><code>dev-dependencies</code> for cargo test/cargo run --example but no <code>dev-default</code> features or similar.</li>
</ul>
<p>Thinks which are in process to get solved:</p>
<ul>
<li>existential <code>impl Trait</code> only working in function return but not Trait return, not type alias and not in struct fields. Which makes it easier to encapsulate it. This makes it inconsistent when you can replace a boxed trait with <code>impl Trait </code> and when not</li>
<li>some parts around arrays, but most have now been fixed or are going to be fixed through const</li>
<li>some parts around <code>macro_rules!</code></li>
</ul>
<p>Two things I think  we should be careful about is to look ahead a bit more.  For example: <code>impl Trait</code> the way we have it now is done exactly IMHO right if we only look at functions/methods. Sure there are some corner cases where existential <code>impl Trait</code> in function parameters would be nice, but they are mostly wrt. macros/code gen and can be worked around. So it's preferable to make it easier to use it for the general case by making it an syntax sugar for generics. But the moment it gets extended to places where the input/output relationship is less clear. Like struct fields. It becomes messy because now you have a situation where both the universal and existential variations make sense depending on how you want to use the struct but for the universal use case we already have generics so we need it in the existential form. But due to it existing in both forms with the same syntax it now becomes harder to explain/learn then when it only would exist in the existential form. Another think is we should be careful with terminology universal/existential <code>impl Trait</code> look like two variations of the same feature. But in the end they are to completely different features which just have some similarity to them IMHO.  Sur in type theory this might not be the case,  but in the way you can use and implement them it is.</p>



<a name="199867893"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Rust%20inconsistencies%2C%20and%20roadmap%20possibilities/near/199867893" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Philipp Korber <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Rust.20inconsistencies.2C.20and.20roadmap.20possibilities.html#199867893">(Jun 05 2020 at 12:21)</a>:</h4>
<p>Just to be clear most of the thinks above are to some degree nit-picking. Non have any major negative influence on my productivity.  And universal <code>impl Trait</code> is still a neat syntax sugar. I just which it wouldn't overlap with existential <code>impl Trait</code>.</p>



<a name="199894531"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Rust%20inconsistencies%2C%20and%20roadmap%20possibilities/near/199894531" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Peter Rabbit <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Rust.20inconsistencies.2C.20and.20roadmap.20possibilities.html#199894531">(Jun 05 2020 at 15:38)</a>:</h4>
<p>I really wish we never added impl Trait for non existential cases.</p>



<a name="199897472"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Rust%20inconsistencies%2C%20and%20roadmap%20possibilities/near/199897472" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> lcnr <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Rust.20inconsistencies.2C.20and.20roadmap.20possibilities.html#199897472">(Jun 05 2020 at 15:59)</a>:</h4>
<p>I personally think of <code>impl Trait</code> as just being an inferred type. So in ret position it is inferred from the function it self, in input position from the function argument.</p>



<a name="199897489"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Rust%20inconsistencies%2C%20and%20roadmap%20possibilities/near/199897489" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> lcnr <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Rust.20inconsistencies.2C.20and.20roadmap.20possibilities.html#199897489">(Jun 05 2020 at 15:59)</a>:</h4>
<p>This interpretation also makes is fairly intuitive for me to extend this to <code>type Foo = impl PartialEq</code>. For me, this is a type alias for which the compiler infers the type.</p>



<a name="199897647"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Rust%20inconsistencies%2C%20and%20roadmap%20possibilities/near/199897647" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> lcnr <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Rust.20inconsistencies.2C.20and.20roadmap.20possibilities.html#199897647">(Jun 05 2020 at 16:00)</a>:</h4>
<p>I mostly got that intuition from a blog by <span class="user-mention silent" data-user-id="121053">varkor</span> : <a href="https://varkor.github.io/blog/2018/07/04/a-new-perspective-on-impl-trait.html">https://varkor.github.io/blog/2018/07/04/a-new-perspective-on-impl-trait.html</a></p>



<a name="200516058"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Rust%20inconsistencies%2C%20and%20roadmap%20possibilities/near/200516058" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Rust.20inconsistencies.2C.20and.20roadmap.20possibilities.html#200516058">(Jun 11 2020 at 08:14)</a>:</h4>
<p>I'd put <code>unsafe</code> meaning two different things at the top of my list</p>



<a name="200522152"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Rust%20inconsistencies%2C%20and%20roadmap%20possibilities/near/200522152" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Dirkjan Ochtman <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Rust.20inconsistencies.2C.20and.20roadmap.20possibilities.html#200522152">(Jun 11 2020 at 09:28)</a>:</h4>
<p>"features and optional dependencies being treated the same from the outside (opt. deps. can be enabled like features) but it's not possible to have a feature and opt. dep. with the same name, nor can a opt. dep. specify other opt. dependencies" is also being worked on (by me, slowly) -&gt; <a href="https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#namespaced-features">https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#namespaced-features</a></p>



<a name="200522200"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Rust%20inconsistencies%2C%20and%20roadmap%20possibilities/near/200522200" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Dirkjan Ochtman <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Rust.20inconsistencies.2C.20and.20roadmap.20possibilities.html#200522200">(Jun 11 2020 at 09:28)</a>:</h4>
<p>My main complaint is the seemingly arbitrary limitations of deref coercion</p>



<a name="200522228"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/Rust%20inconsistencies%2C%20and%20roadmap%20possibilities/near/200522228" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Dirkjan Ochtman <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/Rust.20inconsistencies.2C.20and.20roadmap.20possibilities.html#200522228">(Jun 11 2020 at 09:29)</a>:</h4>
<p>i.e. when a <code>&amp;Vec</code> becomes <code>&amp;[]</code> vs when it doesn't (same for <code>&amp;String</code> and <code>&amp;str</code>)</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>